FIG. 1 is a schematic illustration of a conventional data communication method; FIG. 1 represents prior art. Input data (D1) 10 is processed and encoded to generate corresponding encoded output data (E2) 20. For this purpose, one or more encoding transformations (F) 30 are applied to the input data (D1) 10.
The encoded output data (E2) 20 is often communicated via a data carrier and/or a data communication network to one or more decoders. These decoders are operable to apply one or more decoding transformations (F−1) 80 to the encoded output data (E2) 20 to generate corresponding decoded data (D3) 90.
The input data (D1) 10 often includes various types of data, for example, such as audio data, video data, image data, text data, sensor data, and so forth. In operation, a situation often arises that certain of the various types of data have a higher priority over others. As an example, audio data is given a higher priority for delivery, in an event that the data communication network is unable to deliver video data due to insufficient data bandwidth. Moreover, there arise different priorities for temporal delivery of the different types of data. As an example, audio data needs to be delivered promptly, whereas text data may be less temporally critical.
Thus, it is commonly known that different types of data can have mutually different requirements as regards data transfer. In this regard, some conventional data communication systems have been designed in a manner that they take into account requirements of different types of data communicated therethrough, either in running processes of the data communication systems themselves, or included in their communication protocols, for example, in respect of their real-time operation.
A known prior art technique is the Real Time Messaging Protocol (RTMP) designed by Macromedia Inc., but currently owned by Adobe Systems Incorporated (see reference [1]). The RTMP comprises both a data transfer format and a communication system, wherein data transfer within the communication system is integrated with operation logics that process messages in a prioritized manner so that the messages are not treated equally. Such prioritizing makes it possible, for example, to process and transmit audio data before video data.
However, the RTMP protocol splits the messages into smaller fragments called “chunks”, whose composition is decided by at least one server and at least one client by a mutual agreement. Such decisions are made depending both on a communication protocol used and on various different variables that the RTMP protocol describes (see reference [2]).
The RTMP protocol is usually used together with either the contemporary User Datagram Protocol (UDP) or the contemporary Transmission Control Protocol (TCP), wherein messages are usually split into data chunks whose size is in a range of 128 bytes to 256 bytes.
Furthermore, as data communication networks routinely transfer large quantities of different types of data in various system processes and external processes, it is evident that data transfer capacities of these data communication networks are usually not sufficient unless a given application, device or the data communication networks themselves attempt to control available transfer capacities of the data communication networks using Quality of Service (QoS) schemes (see reference [3]).
A problem encountered with known contemporary data communication networks is that several individual processes executing in an overall system associated with the known contemporary data communication networks often implement their own QoS arrangements mutually independently, programmatically, without taking into consideration needs of other processes being executed in the data communication networks.
Another problem encountered with the known contemporary data communication networks is that an operating system level QoS approach that has been used is potentially not optimized for all types of data being transferred through the data communication networks. As a result, further performance deterioration in the data communication networks can arise, since operating systems of different devices mutually differ. These operating systems often do not have sufficient functionality to take into consideration communication network related needs of other programs, devices and applications, but instead aim to control all data that is transmitted or received through the data communication networks.
Moreover, an operating system or a device may be executing various mutually different anti-virus software and firewall arrangements, whose principal mission is to allow only clean and known data to be transferred. Scanning of data performed by these anti-virus software and firewall arrangements potentially causes delays in data transfer, both during transmission and reception of data.
Moreover, as deployment of the Internet become increasingly geographically common throughout the World, the data communication networks increasingly suffer from a considerable lack of data transfer capacity, which makes them very slow in response times. In a transition phase of software development, it is not understood what really happens in the data communication networks when, for example, data is transmitted one-character-at-a-time or only a few bytes at a time. Such one-character-at-a-time data transfer causes a large amount of so-called almost empty data packets to be circulating in the data communication networks, which is highly inefficient.
To address the aforementioned data transfer problem for one-character-at-a-time, the Nagle's algorithm has been developed (see reference [4]). However, the Nagle's algorithm is not designed to prioritize between different types of data, neither is it a completely functioning model for implementing real-time communication. This is because the algorithm itself collects and stores data until a given data communication network's capacity for a data packet has been reached maximally.
Furthermore, it will be appreciated that data to be transferred is conventionally fragmented both in wired and in wireless data communication networks. A data packet is optionally fragmented regardless of an infrastructure or system settings of a given transmitter or a given receiver, because network nodes optionally have several transmitters that have different-sized capacities. Low-end routers and/or networks optionally split a large-sized data packet into smaller fragments that comply with capabilities of those routers and/or networks, because otherwise they would not be able to transfer the data packet forward in a controlled manner.
For example, wireless General Packet Radio Service (GPRS) networks of mobile phone operators using the Global System for Mobile communications (GSM) standard often conventionally split data packets into smaller fragments (see reference [5]).
When a transmitted data packet is fragmented into smaller packets, as occurs in known data communication systems, new problems are caused as data communication networks join at routers while transmitting the data packet to a given receiver.
Similar types of problems occur especially in wireless data communication networks, such as Wireless Local Area Networks (WLAN) (see reference [6]). Some of the most common problems encountered in the conventional WLAN are packet collisions and packet loss. Thus, more problems are caused when fragmented packets are processed.